AWS Transit Gatewayを使ってAWS Network Firewallを通らないように変更する際にダウンタイムが発生するケースを考えてみた
2024.02.28AWS Network Firewallを通るように変更する際にダウンタイムが発生するのか気になる
こんにちは、のんピ(@non____97)です。
皆さんはAWS Network Firewallを通るように変更する際にダウンタイムが発生するのか気になったことはありますか? 私はあります。
VPC間の通信(East-West)や、オンプレミス-VPC間、インターネット-VPC間の通信(North-South)に対してIPS/IDSの機能が欲しくてNetwork FirewallやGateway Load Balancerを導入したい場面があると思います。
では、実際導入する作業をする際にはどんな影響があるでしょうか。設定作業時に通信ができなくなるダウンタイムがあるのであれば、事前に関係者と作業タイミングを調整する必要があるでしょう。
どんな場面でダウンタイムが発生するのかを確認してみます。
いきなりまとめ
- AWS Transit Gatewayを使ってAWS Network Firewallを通らないように変更する際にダウンタイムが発生するケースは、レスポンスのみNetwork Firewallにルーティングされる場合
- Network Firewallを通るようにする場合でも同様にダウンタイムが発生する
- 非対称ルーティングには気をつけよう
- Transit Gateway route tableで以下のような操作はできないので、一時的な非対称ルーティングは避けられない
- 同時に複数のTransit Gateway attachmentをAssociationする
- 同時に複数のTransit Gateway attachmentをPropagationする
- Transit Gateway route tableに同時に複数のルートを追加する
- リクエスト側のTransit Gateway attachmentのTransit Gateway route tableからルートを変更しよう
考えてみる
Network Firewallを通らないように変更するパターンで考えてみる
Network Firewallを通らないように変更するパターンで考えてみます。
構成はEast-Westです。East-WestというのはVPC間の通信のことを指します。
East-WestやNorth-SouthといったNetwork Firewallのデプロイモデルは以下AWS Blogをご覧ください。
以下のような環境を用意しました。VPC間の通信はNetwork Firewallを通るようになっています。
検証環境はAWS CDKでデプロイしました。使用したコードは以下リポジトリに保存しています。
各EC2インスタンス間でtracerouteを用いて通信できることを確認しました。
$ traceroute 10.1.2.24
traceroute to 10.1.2.24 (10.1.2.24), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 ip-10-1-2-24.ec2.internal (10.1.2.24) 4.205 ms 4.350 ms 4.468 ms
この状態でSpoke VPC用のTransit Gateway route tableにVPC BのTransit GatewayをPropagationします。
Propagation後のSpoke VPC用のTransit Gateway route tableは以下の通りです。動的にルートが追加されていますね。
図にすると以下のような状態です。
この状態で各EC2インスタンス間でtracerouteを用いて通信できるか確認しました。
すると、宛先がVPC BのEC2インスタンスの場合の時のみ通信できなくなることを確認しました。
$ traceroute 10.1.2.24
traceroute to 10.1.2.24 (10.1.2.24), 30 hops max, 60 byte packets
1 * * *
2 * * *
.
.
(中略)
.
.
29 * * *
30 * * *
$ traceroute 10.1.2.24
traceroute to 10.1.2.24 (10.1.2.24), 30 hops max, 60 byte packets
1 * * *
2 * * *
.
.
(中略)
.
.
29 * * *
30 * * *
VPC AからVPC C、VPC BからVPC Aといった通信は引き続き可能です。
$ traceroute 10.1.3.5
traceroute to 10.1.3.5 (10.1.3.5), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 ip-10-1-3-5.ec2.internal (10.1.3.5) 3.403 ms 3.257 ms 3.430 ms
$ traceroute 10.1.1.16
traceroute to 10.1.1.16 (10.1.1.16), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 ip-10-1-1-16.ec2.internal (10.1.1.16) 2.599 ms 2.354 ms 2.340 ms
このように、レスポンスだけNetwork Firewallを通る場合は、レスポンスがNetwork Firewallでドロップされ正常な通信ができません。この動作は以下記事でも確認しています。
要するに、ダウンタイムを抑えるには非対称ルーティングを避ける必要があります。
これはNorth-South(VPCとオンプレミスやインターネット間)においても同様です。
ダウンタイムを抑える方法を考える
ダウンタイムを抑える方法を考えます。
ポイントは以下の2点です。
- 非対称ルーティングを避ける
- 非対称ルーティングであってもレスポンスのみNetwork Firewallを通るような状況にならなければ良い
まず、「非対称ルーティングを避ける」ことが可能かどうか考えます。
非対称ルーティングとなることを避けるためには、リクエストとレスポンスのルーティング情報を同時に変更する必要があります。そのため、具体的には以下のいずれかの操作が求められます。
- 同時にTransit Gateway route tableに複数のルートを変更する
- 同時に複数のTransit Gateway attachmentが参照するTransit Gateway route tableを変更する
しかし、AWSマネジメントコンソールからでもAWS APIレベルでも以下のような操作はサポートされていません。
- 「同時に複数の」Transit Gateway attachmentのAssociationを変更する
- 「同時に複数の」Transit Gateway attachmentのPropagationを変更する
- Transit Gateway route tableに「同時に複数の」ルートを変更する
一回のリクエストでリクエストとレスポンスのルーティング情報について同時に複数の操作ができない以上、必ず一時的な非対称ルーティングが発生します。
そのため、「非対称ルーティングであってもレスポンスのみNetwork Firewallを通るような状況にならなければ良い」ということを心がける必要があります。
例えば、NAT Gatewayを使ったインターネットへのアウトバウンドトラフィックを集約しているケースを考えます。
この状態からNetwork Firewallを通らないようにする場合は、VPC AまたはVPC BのTransit Gateway attachmentをPropagationすることが望ましいです。仮に非対称ルーティングとなったとしてもEgress VPCからのVPC AとVPC Bにリクエストは発生しないため、非対称ルーティングが起因によるパケットのドロップは発生しないと考えます。
もし、仮にEgress VPCのTransit Gateway attachmentをPropagationした場合は少々面倒です。まず、同じ0.0.0.0/0のルートが存在しています。優先順位はPropagationなどの動的ルートよりも静的ルートが優先されるため、通信経路は変化ありません。
この状態で、0.0.0.0/0の静的ルートを削除してしまうと、Egress VPCからのレスポンスをルーティングすることができなくなってしまいます。
このようにTransit Gateway route tableを変更したことによって、通信がどのようにルーティングされるのか影響範囲を理解するのが良いでしょう。
一時的に非対称ルーティングが発生することを注意しよう
AWS Transit Gatewayを使ってAWS Network Firewallを通るように変更する際にダウンタイムが発生するケースを考えてみました。
一時的な非対称ルーティングは避けられないと考えます。パケットがドロップするとワークロードによってはサーバー側では処理が完了しているのに、クライアント側では処理が完了しているように判定される可能性もあります。そのため、作業のタイミングはミッションクリティカルな通信や不整合が発生すると困る通信、リトライ処理が組み込まれていない環境で通信が発生していない場面とするべきだと考えます。
事前に関係者とメンテナンス時間と作業の影響範囲、動作確認方法を握っておくと良いでしょう。
また、事前の検証やリハーサルについてもしっかりとやりたいです。全VPC間、VPC-オンプレミス間の通信に対して影響がある時ような環境だと、その影響範囲も非常に広いです。
なお、今回はNetwork Firewallの例を挙げましたが、Gateway Load Balancerで通信を検査する際にも同様の理由でダウンタイムは発生すると考えます。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[アップデート] AWS Network Firewall で GeoIP フィルタリングがサポートされました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-7688955ca438c58e1daa9713d99135d8/295311a7376d1f262c57d901ac2dc1cd/aws-audit-manager-1)
![[レポート] 生成AIを使ってファイアウォールを強化しよう #NIS375 #AWSreInforce](https://devio2023-media.developers.io/wp-content/uploads/2024/06/eyecatch_awsreinforce2024_1200x630.png)
